JIRA (ATLASSIAN) 資料分析

那天我們在會議室聊到效能最佳化的時候，Imran Parvez突然說：“你們知道有客戶的Jira backlog多到什麼程度嗎？10,000個issue，1000個epic。”我們都愣住了。是的，Jira本身對backlog大小沒限制，可是你想啊，10,000條資料一次性全載入，誰受得了？

這事其實就是個老問題了。Jira是Atlassian開發的，用來幫助敏捷團隊管理任務和使用者故事的，大家都用它來安排sprint。可隨著團隊變大、專案複雜，backlog也越來越長，已經遠超Jira最初設計的承載量。於是，使用者開始抱怨了：開啟backlog頁面慢得嚇人，尤其是那種超大型的backlog——光載入就要等85秒。有時候，頁面甚至要截圖分三段才看得清全部內容，佔滿了整個螢幕的18倍高度。體驗直接拉胯。

於是我們決定動手了。目標很明確：把載入時間從幾十秒壓到3秒以內，至少不能超過使用者的耐心極限。但我們不能簡單粗暴地做分頁或者懶載入，因為要考慮使用者真實的使用場景：他們可能在做規劃（比如估點、roadmap）、在找某個issue（比如查重複）、或者正在新建任務。這些都要求介面要足夠靈活，不能一刀切。

我們一邊呼叫戶反饋，一邊看資料，發現很多使用者其實根本不需要一次性看那麼多issue。真正重要的，是最近有變動的那些——比如剛更新的，剛評論過的，因為這種內容最可能正在處理。而那些幾個月沒動靜的老issue，反而十有八九早就沒人管了。

為了不拍腦袋定方案，我們還做了一輪Crazy 8s的設計腦爆，拉團隊每個人畫出八種思路，最後收斂出一個最靠譜的方案：預設只載入100條issue——其中90條是最近更新的，另外10條是最早的，也就是可能最“歷史悠久”但還沒關掉的那種。同時在介面上增加一個“Show all issues”的入口，如果使用者真的要看全部，再點開也不遲。

上線之後，效果立竿見影。之前10,000個issue的backlog要載入85秒，現在只用4秒，雖然比我們最初設定的3秒還差一點，但效能提升已經達到95%。對於普通backlog（比如400條issue）也從5秒降到2秒，速度整體提升了超過2000%。使用者滿意度也跟著漲了。

我們還貼心地加了個設定選項，讓使用者可以自己決定想預設載入100條、500條，還是全載入。結果呢？上線半年後我們發現，大部分人都默默用著預設的100條，真正改成“載入全部”的，大概只有3500個使用者——相對Jira的整體使用者體量來說，幾乎可以忽略不計。猜都能猜到，他們多半是那種需要全域性操作backlog的PM。

這次最佳化沒用複雜的演算法，也沒換什麼前端框架，但就靠一個小改動和對使用者行為的深刻理解，把體驗從“等到抓狂”變成了“開啟即用”。這個故事也再次提醒我們：最佳化使用者體驗，不一定非得重做，而是得先真正理解使用者到底需要什麼、不要什麼。